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Foreword 



This Technical Specification has been produced by the 3 r Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present rapid development of a diversity of new applications and application environments for mobile usage creates 
a complexity of previously unseen proportions that the UE has to handle. 

The present document introduces a generic model approach for the UE environment; the purpose is not to categorise the 
applications peripherals, but to try to structure the events that are internal and external to, and has to be handled by, the 
MT Core Functions. This means that the structure or grouping of the events should be made from a MT centric 
perspective. Some applications run on the UE side have counterparts in the network. The present document does not 
address the functions in the network. 

The User Equipment functional model used in this specification is defined by the model included in 23.101 [8]. 





UE 



Figure 1 : Functional Model for the User Equipment 
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Scope 



The present document defines the principles for scheduling resources between applications in different application 
execution environment (e.g. MExE, USAT etc.) and internal and external peripherals (e.g. infra-red, Bluetooth, USIM, 
radio interface, MMI, memory etc.). 

The present document is divided in two parts: clause 4 defines a framework for event handling. Clause 5 addresses 
some specific issues. 

Annex A contains an informative background to the problem area. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in the referred documents and the following 
apply: 

call: voice and data calls, USSD, SMS, fax, GPRS calls, supplementary services, etc. 

preferences: includes authorisations, priorities, options, etc. 

authorisation: permission to set up and or receive any call or only certain types of call and access rights to user data 

MT Core Functions: software functions that contain the central logic for the MT, including for instance the scheduling 
of events 
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3.2 Abbreviations 

For the purposes of the present document the following abbreviations apply: 

ME: Mobile Equipment 

MExE: Mobile Execution Environment 

MM: Mobility Management 

MT: Mobile Termination 

RR: Radio Resource 

UE: User Equipment 

USAT: USIM Application Toolkit 

WAP: Wireless Application Protocol 



Principles for the Framework 



The model presented in annex A defines a framework specifying principles for event handling, with the focus on issues 
related to application interaction. Principles for the framework are given below, using the stated definitions. The list is 
not necessarily complete. 



4.1 Basic principles 



1. Irrespective of the principles given below, emergency calls shall override all other calls. 

2. The MT is the central resource and schedules internal and external entities according to the user's preferences and 
external environment. 



4.2 User requirements 



1 . The user shall have the capability to make the ultimate decisions as elaborated below. Additionally, in the case 
where an UE is unmanned, none of the issues below shall render the UE inoperable such that it requires manual 
intervention locally at the UE to restore its use. 

2. The user shall have the capability of selecting preferences interactively and/or via prior set-up in one or more user 
profiles. These shall be valid on a global or on a per application basis. The user's preferences shall be retained even 
in the event of loss of power. 

Preferences can be selected for an application when it is installed, or at any other time thereafter. 

Preferences, notably but not exclusively the priorities, can be modified at any time and this shall have effect at the 

earliest possible opportunity thereafter. 

3. The user shall have the capability to modify authorisations assigned to applications. These shall be valid on a 
global or on a per application basis in one or more user profiles. 

4. The user shall have the option to be advised to what extent an application has been authenticated at installation- 
time, and prevent the application from being installed based on this advice. 

The user shall have the option to be advised about the integrity of an application at installation-time, and prevent 
the application from being installed based on this advice. 

5. The user shall have the capability to abort or suspend any on-going call that has been set up automatically by an 
application. 

6. The user shall have the capability to require that the UE request permission from the user for individual calls, sets 
of calls (for instance all calls by a certain application) or all calls. The user shall have the capability to request the 
UE to record information on individual calls, sets of calls or all calls. 

7. The user shall have the capability to distinguish which entity /application caused a specific event. The UE uses this 
information to support the user's preferences. The UE shall be able to inform the network of entity/application at set 
up time to support trace-ability when a call is set up. 

8. The user's privacy shall be protected. Access to user data (including user profiles and any personal information in 
the UE) and audio functions (this would prevent for instance a mechanism that allows eavesdropping) shall not be 
possible without the user's prior permission. 
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9. The user shall have the capability to request from the UE which applications are present in the MExE environment 
and the (U)SIM, and whether they are running. The user shall also have the capability to request from the UE the 
status of other interfaces as shown in Figure 1, where implemented. 

4.3 Additional requirements on applications 

1. An application shall not assume that it is the only one active. For example where several applications use the same 
interface the application and/or the protocols used over the interface must be able to handle contention. 

2. An application shall not interfere (terminate, suspend or degrade) with on-going calls set up by another application 
without authorisation from the user. For certain combinations of call (e.g., voice/data and USSD messages), 
interference can happen resulting in a level of degradation. 

3. An application shall not assume that it has priority over another application, and shall comply with the user's 
currently selected preferences. 

4.4 Additional requirements on the UE 

1 . The UE shall have the capability to authenticate the source of the application. 

2. The UE shall have the capability to assure the integrity of an application. 

5 Specific Interaction Requirements 

The following clauses detail specific interaction requirements. 

5.1 Bearer Independent Data Transfer 

Bearer Independent Data Transfer is a USIM feature that allows the USIM to request the ME to set up and manage a 
data channel (using a CSD, GPRS, SMS or USSD bearer) using information provided by the USIM. Once the call is 
established, data may be transferred through that data call. The details for the USIM/ME interface are specified in 
3GPP TS 31.101 [4], 31.102 [5], and 31.1 1 1 [6]. The Service Requirements for this are specified in 3GPP TS 22.038 
[7]. 

5.1 .1 Interaction between Core MT functions and Bearer Independent 
Data Transfer Service 

When a Bearer Independent Data Transfer Service is requested by the (U)SAT application, the MT shall: 

• If the MT is idle, set up the data channel as requested, indicating to the user by appropriate means, e.g., with an 
icon, that one or more calls are in progress and confirming to the (U)SAT application. 

• If the MT is not idle and can not service the request without negative impact on ongoing services, then the MT shall 
indicate to the (U)SAT application that the data channel can not be set up. However, if the user has indicated a 
preference for servicing such requests despite the negative impact then the MT may proceed as in the bullet point 
above. 



• 



If the user requests that the call be terminated via MMI or other interface, then the call shall be terminated and the 
(U)SAT application shall be informed. 

• If an external device (TE, Bluetooth device etc.) requests the same resource then that request shall be denied. 

The above behaviour may be modified by a change of user preferences, for example the user may request the MT to 
deny access by the (U)SAT application to a data channel, or the user may request the MT to prioritise a particular 
external device such that a call set up by a (U)SAT application is cleared in order for the external device to be able to 
make a call. 
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5.2 Services and applications external to the MT 

In the tele- and datacom community there exist today use cases for moving internal interfaces out of the MT; they are 
required to fulfil user expectations of what services and features 3G MTs should offer. 

However, discussions on security clearly show that services should be terminated in the MT, while applications can, as 
today, terminate in the TE. A possible UE functionality split should not allow internal interfaces (including USIM) to be 
moved to external interfaces, neither using USAT local link nor other interfaces. 

This is a precaution that shall be taken until suitable procedures against misuse have been found and standardised. 
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Annex A (informative); 
Interaction handling 



In the present document we illustrate possible types of interaction handling for a MT that already can be required or that 
currently are being developed in standards and industry fora. Although it is probable that only a subset of these entities 
will exist at the same time, there is no way of knowing the particular combination of applications or a particular users 
needs relative to this in advance; a general way to handle the co-existence must still be defined. 

A framework, defining general rules for handling this co-existence of several external functions is outlined in the 
present document. The framework states requirements for the behaviour of the external functions as well as principles 
for the co-existence as such. As an example, several of the external functions below, or protocols used by them (e.g., the 
AT-commands) assume a one-to-one relation between them and the MT Core Functions, implying a lack of specified 
mechanisms to handle a multitask environment. 



A.1 The model approach 



The model below proposes a conceptual split, meaning that the entities and their interfaces are logical and need not 
correspond to any physical division. Before the figure is presented some clarifications and general comments are 
needed: 

• The MT Core Functions should be understood as the (collection of) software functions that contain the central logic 
for the MT, including for instance the scheduling of events. 

• With external event is meant interaction that an application/peripheral wants (requests/commands), as well as 
necessary handling of network signalling, user request via the keys, etc. External does not imply whether an 
external interface is used or not. 

• Some network signalling is easy to refer to basic network functions, such as Location Update, while other 
signalling has been invoked by an application. 

• The user can interact intervene directly via keys, etc. This is indicated with the Manual User Interaction entity. The 
user can of course do the same via, e.g., a PC or a MExE application, but the events that such actions create is here 
viewed like the other events that these entities can create. 

• The USIM general Smart Card Functions are split into several logical entities: the Transport Layer Security, 
meaning "basic" 2G/3G security; the USIM Application Toolkit; USIM Application Toolkit Run AT-command; 
and other functions, such as the WIM, the WAP Identity Module, that is being specified. 

• The TE, Terminal Equipment, is a PC or another piece of equipment that can run applications independently. 

• An Intelligent Peripheral could be an advanced charger or a car hands-free installation. 

• The MExE entities are as defined in [2]. 

• Other includes MT resident applications and allows for future applications, and, if that is needed for the model, 
could correspond to other external devices such as a microphone. 

• The interfaces as shown in the figure are logical. In practice the applications run in the MT, a TA or on its own 
separate platform, and the interfaces are then MT internal or external via a physical connector, IrDA, or Bluetooth. 
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Figure A.1 Example of External events that the MT Core Functions should handle 

The figure shows the extent of the complexity that the MT will be expected to handle. It is obvious that a generic 
framework for conflicts, error handling and interactions is needed. In particular, the following issues can be noted: 

1 . Priorities of the event handling - the MT does the scheduling and this should be according to the user' s 
preferences. 

2. User control - the user's wanted / required interaction; his/her knowledge and control of the events; user integrity 
for instance for personal data, the MT position, etc. 

3. Trace-ability - which entity / application has caused a particular event. This information is required input to solve 
several of the other issues. 

4. Consistency - in the actions of the MT Core Functions relative to the specific application. Several applications and 
priority levels interact. 

5. The validity of commands - for instance call validity when the MT is in the Home PLMN or roaming. 

6. Network signalling aspects - how does for instance a dual mode MT treat applications specific to only one of the 
standards. 

7. It might be necessary to look into mechanisms for rejection and termination by the MT Core Function (upon user 
choice) for applications, calls etc. 

8. Testability - the MT manufacturer must be able to as far as possible verify the behaviour of the product, and this 
should be taken into consideration when the framework is specified. Conformance testing, however, is only 
relevant to the extent that already is tested. 

9. Security aspects - for the protection of the MT and the network mechanisms like authentication of the applications 
might be required. 

Further, the entities have different characteristics; this can possibly be used by the framework definitions. The following 
can for instance be noted: 

1. Several of the entities work together with network nodes, some as slaves (e.g., SIM) and others invoking 
commands (e.g., WAP). Others, like the intelligent peripherals, only communicate "locally". 
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2. The entities can be active or passive. In the latter case the MT has more knowledge about the expected behaviour, 
since they only execute functions upon request and cannot issue commands independently. 

3. Some events refer to "basic" network handling, some to manual user interaction, and others relate to application 
invoked functions. "Basic" network interaction should then have priority if such a distinction can be made. 
Consideration should be given to incoming calls. 
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